Не так давно мы писали про приложение VMware Mobile Knowledge Portal, которое позволяет позволяет из одного окна получить доступ к большому количеству документации, лучших практик, видеообзоров, обучающих материалов и прочим документам, которые касаются самых разных продуктов и технологий VMware. Ранее оно было доступно только для iPad, а на днях это приложение вышло как для iPhone, так и для Android-смартфонов.

Помимо поддержки смартфонов, у приложения появился новый дизайн, а также существенно в лучшую сторону поменялась структура категорий по продуктам и технологиям VMware. Теперь в приложении можно почерпнуть много полезного на самые разнообразные темы (их список был значительно расширен).

VMware Mobile Knowledge Portal для iOS (как для iPhone, так и для iPad) можно скачать здесь:

VMware Mobile Knowledge Portal для Android доступен тут:

Также помимо данного средства, на площадках App Store и Google Play можно найти еще одно очень полезное приложение - VMware Partner University:

(вот тут - для Android)

Оно позволяет партнерам VMware получить доступ к содержимому партнерского ресурса VMware Partner Portal со смартфона или планшета, что очень удобно в дороге, когда вы забыли подготовиться ко встрече с заказчиком на тему внедрения, например, VMware vCloud Director.

Можете выбрать интересующую вас тему и смотреть обучающие видео:

А можете читать, скачивать и пересылать документацию по продуктам. Нужная, в общем, вещь.

Не так давно мы писали про поддержку компанией VMware архитектуры OpenStack, которая предоставляет специальный виртуальный модуль для интеграции с этой облачной архитектурой (а вот тут - про поддержку со стороны Red Hat). Ну а на днях немецкая компания SUSE (с некоторых пор очень дружащая с VMware) выпустила свою облачную платформу SUSE Cloud 3 на базе платформы OpenStack с поддержкой инфраструктур VMware vSphere.

SUSE Cloud 3 предназначена для построения IaaS-инфраструктур как сервис-провайдеров, так и для частных облаков компаний, предоставляющих своим пользователям ресурсы сервисов виртуализации, в том числе на базе гипервизора VMware ESXi. Облако SUSE Cloud третьей версии построено на базе релиза Havana архитектуры OpenStack.

Особенности SUSE Cloud 3:

• Улучшенные средства управления. Модуль оркестрации позволяет автоматизировать операции с виртуальными машинами на базе предопределенного набора шаблонов сценариев. Теперь можно управлять последовательностью действий для таких объектов, как серверы, "плавающие" IP-адреса, тома и домены безопасности для определенных приложений, при этом определяется взаимосвязь между объектами.
• Модуль Telemetry предоставляет средства мониторинга использования ресурсов облака объектами инфраструктуры, а также пользователями. Собранные данные могут отдаваться биллинговым системам. Кроме того, модуль Telemetry интегрируется с модулем Orchestration, что позволяет, например, развертывать и списывать ресурсы (виртуальные машины) по мере нарастания и спада нагрузки, соответственно.
• Возможность использовать в качестве бэкэнд-инфраструктуры инсталляцию VMware vSphere (связь происходит через сервер vCenter), при этом поддерживается решение для виртуализации сетей VMware NSX. Кроме ESXi поддерживаются также гипервизоры KVM, Xen и Microsoft Hyper-V.
• Упрощенная процедура развертывания компонентов облака и их обновления. Установщик SUSE Cloud 3 построен на базе проекта Crowbar, который позволяет автоматизировать операции развертывания.
• SUSE Cloud 3 включает в себя поддержку компонентов архитектуры OpenStack Block Storage (Cinder) и OpenStack Networking (Neutron), а также поддерживает все необходимые OpenStack API, что позволяет использовать множество решений от партнеров OpenStack.
• В состав платформы включен Cloud Administration Server - централизованная консоль управления облачной инфраструктурой, а также узлы Cloud Control Nodes (управление пользователями и правами), Compute Nodes (вычислительные ресурсы - исполнение ВМ) и Storage Nodes (хранилища данных). Кроме этого используются модули Nova (контроллер вычислительных ресурсов), Glance (библиотека образов и развертывание ВМ), а также средство аутентификации Keystone. Интерфейс управления построен на базе компонента Dashboard.
• Также в дистрибутив включены драйверы EMC, что позволяет управлять хранилищами EMC VNX прямо из коробки.

Пробную версию дистрибутива SUSE Cloud 3 можно скачать по этой ссылке. Детальная информация по платформе доступна тут. Ну а средства управления в виде виртуальных модулей можно скачать здесь.

Как знают пользователи VMware vSphere из сегмента малого и среднего бизнеса, для пакетов VMware vSphere Essentials Plus (или обычного Essentials) есть специальное издание vCenter Server Essentials, которое позволяет управлять не более чем тремя хостами ESXi для соответствующих изданий. На самом деле, это обычный vCenter Server Foundation, который приспособлен для Essentials (Plus).

Ограничение на 3 хоста, не более 2-х процессоров в каждом - это условие лицензии VMware. Однако раньше можно было сделать вот какой хак - купить две лицензии Essentials/Essentials Plus и один сервер vCenter Standard - и можно управлять инфраструктурой (например в стойках, размещенных на разных этажах или в разных филиалах) из одной точки. Это как бы не совсем по лицензии, но в целом к такой конфигурации никто претензий не имел.

Однако, начиная с VMware vSphere 5.0, ситуация изменилась - теперь в таком случае появляется ошибка vCenter:

На такой случай компания VMware теперь предлагает программу Retail and Branch office, кратко называемую "ROBO". Она позволяет вам купить лицензии Essentials/Essentials Plus на 10 физических процессоров серверов и управлять ими всеми с одного сервера vCenter. Это отлично подходит для тех компаний, которые имеют несколько филиалов, и у которых есть необходимость объединить их единой точкой управления.

Отдельным аддоном можно купить 10 лицензий VMware Virtual Storage Appliance, которые подходят только для Essentials Plus:

Надо понимать, что в случае лицензирования по программе ROBO - вы можете управлять каждым сайтом Essentials/Essentials Plus отдельно, либо купить еще лицензию на vCenter Standard - и управлять всеми инфраструктурами филиалов централизованно (поддерживается до пяти площадок). Последний вариант, конечно же, удобнее.

Лицензии на 10 процессоров хостов ESXi вы можете как удобно распределить между филиалами.

Как знают те из вас, кто интересуется программами обучения VMware, сертификация VMware VCP, являющаяся одной из самых востребованных на рынке, требует предварительного прохождения авторизованных учебных курсов и последующей сдачи экзаменов.

Так вот, с недавних пор, курсы эти можно пройти дома или у себя в офисе, при этом они будут полностью соответствовать требованиям программы VMware Certified Professional. На данный момент доступны курсы только по VMware vSphere 5.1, но эта сертификация по-прежнему действующая и вполне катит под требования к партнерской программе VMware, например.

Сейчас вот тут доступны следующие курсы (только английский):

• English: VMware vSphere: Install, Configure, Manage [V5.1]
• English: VMware Horizon View: Install, Configure, Manage [V5.2]

Курс Install, Configure, Manage содержит в себе 24 лабораторных работы, которые выполняются в облачном окружении. Вот список лаб, если кому интересно:

• Lab 1: Installing VMware vSphere Graphical User Interfaces Lab
• Lab 2: Configuring VMware ESXi
• Lab 3: Working with Virtual Machines
• Lab 4: Configuring the vCenter Server Appliance
• Lab 5: Standard Virtual Switches
• Lab 6: Accessing ISCI Storage
• Lab 7: Accessing IP Storage
• Lab 8: Managing VMware vSphere VMFS
• Lab 9: Using Templates and Clones
• Lab 10: Modifying a Virtual Machine
• Lab 11: Migrating Virtual Machines
• Lab 12: Managing Virtual Machines
• Lab 13: Managing vApps
• Lab 14: Access Control
• Lab 15: User Permissions
• Lab 16: Resource Pools
• Lab 17: Monitoring Virtual Machine Performance
• Lab 18: Using Alarms
• Lab 19: Using vSphere High Availability
• Lab 20: Designing a Network Configuration
• Lab 21: Configuring VMware vSphere Fault Tolerance
• Lab 22: vSphere Distributed Resource Scheduler
• Lab 23: VMware vSphere Update Manager
• Lab 24:Installing VMware vCenter Server

Само обучение доступно в течение 30 дней или 30 часов активного времени, в зависимости от того, что истечет раньше. Для тех, кто хочет посмотреть, что это такое, есть бесплатная возможность посмотреть первые два следующих модуля:

• Module 1: Course Introduction and Logistics
• Module 2: Introduction to VMware Virtualization, which includes:

Доступны они будут в течение 90 минут. Получить бесплатный доступ к ним можно по этой ссылке.

Правда стоит это удовольствие чуть больше, чем дофига:

Зато можно пройти его в любое время, ведь курсы (в том числе онлайн) проводятся далеко не каждый день.

Ну а для тех кто хочет дешевле (в два раза, между прочим!) мы советуем авторизованные курсы от HP. Это не реклама - там просто дешевле, чем в любом другом месте + дают бесплатный ваучер на сдачу экзамена:

Нашли дешевле (с учетом ваучера)? Пишите в каменты!

Некоторые администраторы VMware vSphere используют так называемые "Custom Attributes" для виртуальных машин на платформе VMware vSphere. Эти атрибуты могут быть полезны, когда вы хотите добавить какие-нибудь заметки к виртуальной машине, отражающие ее свойства - например, географическое положение, принадлежность системы или ее критичность (эти атрибуты, например, использует Veeam Backup and Replication для сохранения даты последнего бэкапа ВМ). Кстати, начиная с версии VMware vCenter 5.1, кастомные атрибуты на vCenter были заменены "тэгами" (tags).

Так вот в VMware vSphere Web Client функциональности отображения Custom Attributes, к сожалению, нет. Поэтому один из vExpert'ов написал специальный плагин vSphere Web Client Plugin for Custom Attributes (доступен только после регистрации в данной группе VMUG).

Как поставить плагин в VMware vCenter, который установлен в Windows-машине:

• Остановить службу vSphere Web Client service.
• Скопировать папку haif-customfields-ui в папку C:\Program Files\VMware\Infrastructure\vSphereWebClient\plugin-packages.
• Запустить службу vSphere Web Client service.

Если вы используете VMware VCSA (vCenter Server Appliance):

• Остановить службу vSphere Web Client service командой:

/etc/init.d/vsphere-client stop

• Скопировать папку haif-customfields-ui в папку /usr/lib/vmware-vsphere-client/plugin-packages
• Запустить службу vSphere Web Client service командой:

/etc/init.d/vsphere-client start

В результате в свойствах виртуальной машины в Web Client в виде портлета появятся Custom Attributes:

Мы часто пишем о решении номер 1 для резервного копирования и репликации виртуальных машин Veeam Backup and Replication, которое уже стало стандартом де-факто для бэкапа ВМ в виртуальных инфраструктурах VMware (а много где и в средах Microsoft Hyper-V).

Некоторое время назад мы писали о новых возможностях версии Veeam Backup and Replication 7.0 R2, а совсем недавно вышел патч Veeam Backup and Replication 7.0 R2 Patch 3, который принес не только исправления ошибок, но и несколько полезных новых возможностей.

Итак, новые функции по категориям:

Engine

• Существенно снижена нагрузка на базу SQL, что улучшает производительность задач резервного копирования, кроме того быстрее работает интерфейс.

vSphere

• Улучшена логика сбора информации об иерархии объектов сервера vCenter, что ускоряет построение списка ВМ.
• Алгоритм балансировки нагрузки может быть теперь настроен таким образом, чтобы использовался backup proxy, который установлен на этом же хосте. Для этого используется ключ реестра EnableSameHostHotaddMode (DWORD).
• Задача репликации при ошибке прекращается мгновенно, вместо того, чтобы шуршать над вспомогательными операциями.

Hyper-V

• Добавлены таймауты для всех операций со снапшотами (создание, удаление, чтение данных и импорт на off-host proxy) для предотвращения проблем с зависнувшими снапшотами.
• Теперь время жизни снапшота тома можно настраивать в ключе реестра hvSnapshotLifeTimeHour (DWORD). По умолчанию установлено 72 часа, но может понадобиться и более длительное время для создания резервной копии на медленном "железе".
• Возможность настройки таймаутов по взаимодействию с SCVMM в ключе реестра SCVMMConnectionTimeoutMinutes (DWORD).

1-Click FLR

• Поддержка загрузки файлов размером более 4 ГБ.

Built-in WAN acceleration

• Производительность обработки данных была улучшена на 25% по сравнению с изданием R2.

Multi-OS File level recovery

• Добавлена поддержка имен файлов в юникоде.

Tape

• Поддержка имен файлов более 260 символов и имен директорий более 248 символов.
• Поддержка устройств, которые не посылают ошибку при попытке записи на защищенный от записи носитель.
• Поддержка устройств, которые не посылают событие end of media (заполненность устройства) - таким поведением отличаются некоторые приводы IBM. Джоба Veeam сама контролирует заполненность этого устройства.
• Поддержка устройств, которые некорректно обнаруживают приводы.

User interface

• Размеры колонок и правила сортировок сохраняются для каждого пользователя.
• Возможность отключения GFS retention для задачи резервного копирования, что позволяет сделать изолированную резервную копию ("забрать бэкап").
• Прогресс процесса восстановления файла резервной копии теперь отображается в соответствующей задаче.

Rotated media
В этом релизе появилась полная поддержка устройств типа rotated media (съемные и заменяемые устройства) для всех режимов и типов задач резервного копирования. Эта функциональность контролируется следующими ключами реестра:

• ForceCreateMissingVBK (DWORD) - включает поддержку устройств типа "rotated drives" (значение 1). В этом случае, если Veeam B&R обнаруживает отсутствие цепочки файлов резервной копии, то он создает новый полный бэкап и новую цепочку файлов (вместо того, чтобы упасть).
• ForceDeleteBackupFiles (DWORD) - автоматически зачищает файлы резервных копий, если какой-либо из файлов цепочки резервной копии отсутствует (например, диск заменили другим, на котором есть старые резервные копии). Если установлено значение 3, то чистится вся папка задачи РК. Если же установлено 5, то чистится вся корневая папка с репозиторием.

Скачать решение Veeam Backup and Replication 7.0 R2 Patch 3 можно по этой ссылке: http://www.veeam.com/kb1854. Там же приведены и дополнительные подробности о релизе.

Некоторое время назад компания VMware выпустила полезную утилиту VMware vSphere Mobile Watchlist, которая позволяет мониторить виртуальную инфраструктуру с телефона на Android и iOS / iPhone, а также своевременно обнаруживать и решать проблемы, например, с пляжа, когда у вас нет под рукой даже планшета.

vSphere Mobile Watchlist предназначен для трех простых вещей:

• Посмотреть на инфраструктуру и обнаружить проблему.
• Попытаться ее исправить, перезагрузив ВМ или хосты.
• Если не помогло - сообщить о проблеме персоналу своей компании, который, в отличе от вас, находится на работе.

В качестве платформы, чтобы работал vSphere Mobile Watchlist, должна использоваться VMware vSphere 5.0 или более поздняя версия.

Основные возможности vSphere Mobile Watchlist:

• Создание списка ВМ для мониторинга (собственно, Watchlist) - несколько машин из инвентори, которые будут отслеживаться. Можно создавать несколько списков.
• Просмотр состояния ВМ - статус (включена/выключена), жизнедеятельность, консоль (удобно для того, чтобы узнать, не появилось ли синего экрана или сообщений об ошибках) и связанные объекты. Также доступны показатели загрузки процессора, памяти и места на диске.
• Получение в случае сбоя ВМ сообщения об ошибке в виде алерта, к которому прилагается не только описание сути проблемы, но и ссылка на соответствующую статью KB.
• Операции по изменению состояния ВМ - Start/Stop/Suspend/Reboot (в том числе "мягкие" Shudown и Restart).
• Возможность сообщить о проблеме (вместе со статьей KB) своим коллегам.

Требования к смартфонам/планшетам:

• iOS 7.0 или более поздняя. Подерживается iPhone, iPad, iPod Touch
• Android 4.0.3 или более поздняя

Скачать VMware vSphere Mobile Watchlist можно по этим ссылкам:

• Для iOS
• Для Android

Комьюнити по продукту доступно по этой ссылке. В общем-то, это очередная погремушка, но в экстренном случае она может оказаться кому-то полезной.

На днях компания VMware обновила свой главный документ о производительности и мониторинге виртуальной инфраструктуры - VMware vSphere 5.5 Monitoring and Performance.

В этом документе (или даже, можно сказать, книге) на 175 страницах рассказывается о лучших практиках по отслеживанию производительности серверов VMware ESXi 5.5 под управлением VMware vCenter 5.5.

Основное содержание документа:

• Monitoring Inventory Objects with Performance Charts - полное описание графиков и счетчиков производительности в VMware vCenter.
• Monitoring Guest Operating System Performance - немного о мониторинге гостевой ОС виртуальной машины.
• Monitoring Host Health Status - проверка жизнедеятельности хостов и выявление проблем.
• Monitoring Storage Resources - построение отчетов по хранилищам и графическое представление Storage maps.
• Monitoring Events, Alarms, and Automated Actions - просмотр событий для объектов vCenter, алармы и действия по срабатыванию триггеров.
• Monitoring Solutions with the vCenter Solutions Manager - мониторинг расширений vCenter.
• Performance Monitoring Utilities: resxtop and esxtop - утилиты для мониторинга производительности из командной строки (там же есть расшифровки всех счетчиков). Об этом мы пишем тут.
• Monitoring Networked Devices with SNMP and vSphere - мониторинг хостов по протоколу SNMP и настройка агентов.
• System Log Files - просмотр активностей виртуальной инфраструктуры в лог-файлах журналов.

Документ обязателен к прочтению системным администраторам VMware vSphere, а также всем тем, кто готовится к различным экзаменами, например VMware VCP.

Не так давно мы писали о том, что обновилась бета-версия решения StarWind SAN V8 (это было сделано неофициально), предназначенного для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин. На днях же была выпущена обновленная официальная версия - StarWind SAN V8 Beta 3.

Напомним сначала основные новые возможности StarWind V8:

• L2 Flash Cache - кэш уровня L2, который работает непосредственно с кэшем уровня L1 в RAM, что существенно улучшает производительность.
• Файловая система LSFS, которая изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины (это дело недалекого будущего). Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что также существенно увеличивает производительность.
• Inline-дедупликация StarWind, которая не создает нагрузку на подсистему хранения и не "крадет" IOPS'ы у продуктивного хранилища.
• Simplified and improved GUI - улучшенный интерфейс мастеров развертывания хранилищ для Windows Server 2012 с поддержкой скриптов PowerShell.
• Возможность интеграции с механизмом SMI-S для Windows Server 2012 R2.
• Massive Scale-Out storage architecture - возможность масштабирования узлов кластера хранилищ до любого числа (а не только 3 как сейчас).
• Asynchronous WAN-replication - возможность асинхронной репликации между узлами и возможность создания катастрофоустойчивого решения для хранилищ.
• Поддержка примитивов VAAI для устройств на одном узле и устройств с синхронной репликацией: поддерживаются команды WRITE SAME, EXTENDED COPY, ATS.
• Репликация конфигурации узла, включая информацию о снапшотах, что позволяет в случае сбоя сохранить созданную оригинальную конфигурацию и реплицировать ее уже, например, на третий узел.

А вот какие улучшения появились в предрелизной версии StarWind SAN V8 Beta 3 (по сравнению с прошлой "неофициальной" бета-версией):

Улучшения устройств LSFS

• Обработка размера устройства и его заполненности напрямую от нижележащего физического устройства.
• Исправлен баг, приводивший к ошибкам записи на диск

Синхронная репликация устройств LSFS

• Пофикшены ошибки при работе со снапшотами (удаление и создание).
• Поправлена ошибка, когда один из HA-узлов почему-то выпадал в состояние "unsynchronized".

VSS-провайдеры для поддержки устройств с LSFS

• Hardware VSS provider - теперь доступен для LSFS-устройств, в том числе с синхронной репликацией.
• Software VSS Provider - доступен для обычных LSFS-устройств.

Asynchronous WAN-replication - возможность асинхронной репликации между узлами и возможность создания катастрофоустойчивого решения для хранилищ.

• Теперь возможна репликация даже на очень медленных каналах.
• Пофикшено монтирование снапшотов.
• Улучшен алгоритм репликации.
• Небольшие доработки в механизме поддержки VAAI.

Скачать новую StarWind SAN V8 Beta 3 можно по этой ссылке. Release notes доступны тут.

Интересную статью об установке VMware Tools недавно написал Андрэас. Приведем здесь основные моменты. Итак, во время установки VMware Tools в Windows-машине на VMware vSphere мы видим следующие компоненты:

Для многих организаций важно, какое именно ПО устанавливается на сервер или рабочую станцию, чтобы можно было не устанавливать ненужные сервисы и компоненты, увеличивающие площадь атаки для злоумышленника.

Кроме этого, интересно, конечно же, взглянуть на то, что находится внутри MSI-пакета setup.exe (или setup64.exe для 64-битных систем), который находится в установочном образе VMware Tools ISO, а также узнать о параметрах его установки.

Итак, берем утилиту Microsoft Orca editor из состава Windows Installer Development Tools, открываем наш MSI-пакет и переходим на вкладку Features. Там мы видим следующее дерево компонентов (то, что выделено жирным - отсутствует в GUI):

• Toolbox (Toolbox)
• Perfmon (WMI Performance Logging) - не устанавливается для Workstation/Fusion.
• Unity (Support for Unity feature) - поддержка функций Unity - только для Workstation/Fusion.
• Plugins
• TrayIcon (Display the Tray Icon) - иконка тулзов в трее, можно отключить, если поставить свойство MSI-пакета NO_TRAYICON=1.
• Drivers (VMware Device Drivers)
• PVSCSI (Paravirtual SCSI) - драйвер паравиртуализованного виртуального диска, недоступен если ОС Windows 2000 или более старая.
• MemCtl (Memory Control Driver) - драйвер управления памятью для поддержки технологии Memory Ballooning.
• Mouse (PS2 Mouse Driver) - драйвер мыши PS2 (legacy).
• MouseUSB (USB Mouse Driver) - драйвер мыши USB.
• SVGA (SVGA Driver) - видеодрайвер.
• Audio (Audio Driver) - аудиодрайвер, устанавливается по умолчанию, не ставится для Windows XP-32bit, Windows 2000 и более ранних ОС.
• VMXNet (VMXNet NIC Driver) - драйвер виртуального сетевого адаптера первого поколения, устанавливается по умолчанию для ОС Windows 2000/XP/2003/2008/2008R2.
• VMXNet3 (VMXNet3 NIC Driver) - драйвер последнего поколения виртуального сетевого адаптера, устанавливается по умолчанию, не ставится для Windows 2000 и более ранних.
• VSS (Volume Shadow Copy Services Support) - поддержка механизма VSS (в том числе для систем резервного копирования). Устанавливается для Windows 2003/Vista и более поздних. Не устанавливается, если хотя бы один из сервисов ComSysApp или MSDTC отключен.
• VMCI (VMCI Driver)
• VShield (vShield Drivers) - не отмечен по умолчанию, ставится только если машина работает на ESXi в Windows XP SP2+/2003 SP1+  или более поздних версиях.
• Hgfs (Shared Folders) - компонент общих папок между хостом и гостевой ОС для VMware Fusion/Workstation (для них устанавливается по умолчанию, для ESXi по умолчанию отключен).
• BootCamp (Mac BootCamp Support - VMware Fusion only) - устанавливается только для VMware Fusion/Workstation, начиная с Windows XP.
• Buslogic (SCSI Driver) - устанавливается только для Windows 2000 и 32-битных версиях XP/2003. В других случах не ставится.
• Sync (Filesystem Sync Driver) - устанавливается только на ESXi и только для Windows 2000 и 32-битных версиях XP/2003. Необходим для систем резервного копирования для "заморозки" файловой системы во время снятия бэкапа, чтобы он получился консистентным. На более поздних ОС уже работает VSS-компонент.
• WYSE (Wyse Multimedia Support) - поддержка терминалов WYSE. Не устанавливается по умолчанию, доступно только на Windows XP и 2003.
• Common
• Microsoft_x86_Dll

Как можно заметить, устанавливаются или нет некоторые компоненты при установке VMware Tools зависит от того, какая версия Windows используется, ну и, конечно, где устанавливается пакет - на VMware ESXi или на настольной платформе VMware Workstation/Fusion.

В документации по VMware Tools рассказано о том, как можно добавлять или исключать компоненты из установки, а также устанавливать тулзы в silent-режиме (то есть, без GUI) и без перезагрузки гостевой ОС.

Например, вот такая команда установщика установит VMware Tools в тихом режиме для Windows-на ESXi, при этом у вас не будет ненужных компонентов, а также иконки VMware Tools в трее:

setup[64].exe /s /v /qn ADDLOCAL=All REMOVE=Hgfs,WYSE,Audio,BootCamp,Unity,VShield,TrayIcon

А эта команда сделает то же самое, но еще и предупредит перезагрузку, а также запишет лог установки в специальный файл (это все одна строчка):

setup[64].exe /s /v /qn /l*v "%TEMP%\vmmsi.log" REBOOT=R ADDLOCAL=All REMOVE=Hgfs,WYSE,Audio,BootCamp,Unity,VShield,TrayIcon

Такая команда обновит VMware Tools с момента прошлой установки:

setup[64].exe /s /v /qn REINSTALLMODE=vomus ADDLOCAL=All REMOVE=Hgfs,WYSE,Audio,BootCamp,Unity,VShield,TrayIcon

Более подробно о параметрах установки VMware Tools можно прочитать в KB 2000399.

Если же вы хотите проверить, какие компоненты VMware Tools установлены, то для этого есть скрипт WiListPrd.vbs, вывод которого выглядит следующим образом:

> cscript WiListPrd.vbs "VMware Tools" f

У VMware обнаружилась любопытная вещица - "советчик" по выбору продуктов - Virtualization Advisor Tool. Несмотря на то, что это маркетинговый инструмент, вполне можно потратить пару минут, чтобы прокликать его - тем более, что он может дать рекомендации и тем, у кого решения VMware vSphere и VMware View уже есть.

Итак, запускаем утиль и выбираем нашу основную ИТ-цель (в контексте виртуализации, конечно же):

Определяем основную необходимость в средствах управления:

Говорим, сколько у нас физических серверов и виртуальных машин:

Говорим, сколько ПК:

Указываем, сколько площадок в нашей организации:

Выбираем вендора - VMware или не VMware :)

Сообщаем, сколько у нас ИТ-персонала на управление инфраструктурой, и в каком режиме он работает:

Получаем результат - нам нужен пакет VMware vSphere with Operations Management Suite Standard Acceleration Kit.

Теперь попробуйте вы.

Раньше пользователи думали о том, как нужно развертывать VMware vCenter - в виртуальной машине или на физическом сервере. Теперь время этих размышлений прошло - большинство ставит его в виртуальной машине. Однако с появлением готового модуля vCenter Server Appliance (vCSA) встал немного другой вопрос - использовать ли готовый vCSA или устанавливать vCenter в Windows. Попробуем разобраться.

Не так давно мы уже писали о средстве vCenter Support Assistant, представляющем собой бесплатный плагин к VMware vCenter Server, который призван облегчить сбор диагностических данных об инфраструктуре VMware vSphere, а также помочь обратиться в техническую поддержку.

На днях была выпущена обновленная версия VMware vCenter Support Assistant 5.5.

Напомним, что Support Assistant через плагин к vSphere Client позволяет работать с реквестами в техподдержку, вне зависимости от того как она куплена - на базе подписки или по инцидентам

В vCenter Support Assistant 5.5 появилась новая функциональность, касающаяся автоматизации процесса сбора и загрузки данных, необходимых технической поддержке VMware. Кроме того, диагностические данные передаются по защищенному каналу HTTPS или по FTP напрямую в VMware, минуя посредников. Также было исправлено несколько ошибок.

Более подробно обо всем этом можно почитать в Release Notes. Скачать VMware vCenter Support Assistant 5.5 можно по этой ссылке.

Как многие из вас знают, в виртуальной инфраструктуре VMware vSphere некоторое количество программного обеспечения распространяется в виде виртуальных модулей (Virtual Appliances), представляющих собой готовые виртуальные машины с необходимыми сервисами внутри.

К ним, например, относятся следующие вспомогательные модули от самой VMware:

• vCenter Server Virtual Appliance 5.5 (VCVA) - главный сервер управления виртуальной инфраструктурой vSphere на базе ОС SUSE Linux.
• vCenter Orchestrator 5.5 (vCOva) - средство автоматизации операций для виртуальных машин и хост-серверов.
• vCenter Operations Manager 5.7.1 (vCOPs) - средство комплексного мониторинга и анализа виртуальной среды.
• vCenter Infrastructure Navigator 2.0 (VIN) - решение для автоматического обнаружения и визуализации компонентов приложений и зависимостей инфраструктуры.
• vCloud Automation Center Virtual Appliance 6.0 (vCACva) -  средство управления облачной инфраструктурой предприятия (SaaS, PaaS, IaaS) за счет единого решения, построенного поверх VMware vCloud Director.
• vCenter Management Assistant (vMA) - вынесенная "сервисная консоль" за пределы хост-серверов ESXi в отдельный виртуальный модуль, с которого удобно выполнять консольные команды RCLI (например, мониторинга - resxtop), а также хранить и запускать различные скрипты. 
• VMware Log Insight - централизованное средство сбора и анализа логов, о нем мы уже писали тут.
• Horizon Workspace Manager 1.5 (наша статья тут) -  средство автоматизации инфраструктуры виртуальных и физических ПК.
• vCloud Connector 2.5.1 (vCC) - средство миграции виртуальных машин на платформе VMware vSphere из частного облака предприятия в публичное хостинг-провайдера и обратно.

Все эти модули (а также и модули от сторонних производителей), будучи неотъемлемыми компонентами виртуальной среды, нуждаются в защите. Чтобы облегчить эту задачу пользователям, компания VMware выпустила документ "Hardened Virtual Appliance Operations Guide", в котором на 16 страницах вкратце рассказывают о том, как нужно защищать эти виртуальные модули в следующих контекстах:

• Root password - поставить нормальный пароль (сменить дефолтный!).
• Password Expiry - поставить нормальную политику устаревания паролей.
• Выполнить скрипт повышенной безопасности для параноиков (Dodscript.sh - сделан для Минобороны США). Там же написано про то, как поменять Security Banner (то есть скрин логина в консоль ESXi, на котором вывешено предупреждение об ответственности за несанкционированный доступ).
• Secure Shell, Administrative Accounts, and Console Access - использовать защищенный доступ к консоли виртуальных модулей.
• Time Sourcing and Synchronization - применять синхронизацию времени с доверенным источником.
• Log Forwarding – Syslog-ng and Auditd - перенаправлять собираемые логи на отдельный защищенный сервер.
• Boot Loader (Grub) Password - поставить пароль на загрузчик, исключающий также загрузку в Single user mode.
• Отключить сервисы NFS и NIS.

Начинание это, безусловно, является хорошим шагом со стороны VMware в плане обеспечения безопасности виртуальных модулей и инфраструктуры в целом. Но как-то маловато 16 страниц, вы не находите?

Мы довольно много пишем про кластеры хранилищ VMware Virtual SAN (VSAN), которые создаются на базе локальных дисков серверов VMware ESXi (например, тут и тут, а в последний раз - тут). А сегодня мы хотим рассказать о калькуляторе, который может пригодиться для расчета необходимой емкости хранилищ под Virtual SAN.

Написал его Duncan Epping, известный специалист по VMware vSphere и блоггер - один из немногих, которому можно верить.

Калькулятор рассчитывает общее количество требуемого дискового пространства (HDD и SSD-диски) как для кластера в целом, так и для одного хоста VMware ESXi, принимая в качестве исходных данных следующие параметры:

• Количество ВМ в кластере хранилищ.
• Объем оперативной памяти машины (vRAM).
• Размер виртуального диска машины.
• Число хостов, используемое для построения кластера.
• Параметр Failures to tolerate (о нем мы писали тут).
• Процент дискового пространства на метаданные и прочие издержки виртуализации хранилищ (по лучшим практикам - где-то 10%).
• Процент пространства, которое занимает SSD-накопитель от дискового пространства на базе HDD-дисков хоста ESXi.

Поиграть с калькулятором дискового пространства для Virtual SAN можно по этой ссылке.

Для тех из вас, кто по причине отсутствия купленной подписки, лени или еще какой другой, использует старую версию платформы виртуализации VMware vSphere 5.1, компания VMware выпустила обновление VMware vCenter Server 5.1 Update 2.

Что нового в Update 2:

• vCenter Server 5.1 теперь поддерживается на платформе Windows Server 2012 R2.
• Возможность кастомизации нескольких дополнительных гостевых ОС через vCenter:
  • Windows 8.1
  • RHEL 6.4
  • Windows Server 2012 R2
  • SLES 11 Service Pack 3
• Добавлена поддержка СУБД Microsoft SQL Server 2012 Service Pack 1.
• Обновление протокола OpenSSL до версии openssl-0.9.8y.
• Исправления ошибок, которые можно найти вот тут.

Скачать VMware vCenter Server 5.1 Update 2 можно по этой ссылке.

Кроме этого, вышел также и VMware ESXi 5.1 Update 2, где почти ничего не изменилось:

• Появилась поддержка новых гостевых ОС (их список есть в VMware Compatibility Guide).
• Было исправлено несколько ошибок, список которых приведен вот тут.

Скачать VMware ESXi 5.1 Update 2 можно по этой ссылке.

Несколько недель назад компания VMware выпустила обновление ESXi 5.5.0 Driver Rollup 1, представляющее собой ISO-образ с самим ESXi 5.5 и дополнительными драйверами. Этот образ подходит только для чистой установки на хост и не поддерживает режим обновления (Upgrade).

VMware ESXi 5.5.0 Driver Rollup 1 содержит в себе драйверы IOVP certified drivers (IOVP  - I/O Vendor Partner Program), то есть драйверы от производителей, которые добавились или обновились с момента выхода ESXi 5.5.

Обновлены были драйверы оборудования следующих производителей:

• Broadcom
• Cisco
• Emulex
• Fusion-io
• HP
• Hitachi
• Intel
• LSI Corporation
• QLogic
• Virident Systems

Release Notes для ESXi 5.5.0 Driver Rollup 1 доступны по этой ссылке.

Мы уже немало писали про кластеры хранилищ VMware Virtual SAN (последнее - тут и тут), а сегодня рассмотрим механизм работы запросов на чтение блоков, который описал в своем блоге Duncan Epping.

Итак, схема кластера VMware Virtual SAN:

Здесь мы видим такую картину - виртуальная машина находится на хосте ESXi-01, а ее блоки размером 1 МБ размещаются на хранилищах разных хостов. При этом блоком 1 владеет ESXi-01, а блоком 2 - ESXi-03. Хост ESXi-02 не принимает участия в обработке запросов ввода-вывода.

Схема работы запроса на чтение проста - сначала проверяется наличие блока в кэше на чтение (Read cache), и если там блока не оказывается, то проверяется Write buffer на хранилище SSD (если блок еще не успел записаться на HDD) и непосредственно сам HDD-диск. В данном случае блок 1 нашелся на SSD-диске в кэше на чтение.

Второй же блок обслуживается хостом ESXi-03, но его не оказалось в кэше на чтение, и он читается с HDD-диска. Тут надо отметить, что кластер Virtual SAN помещает блоки в кэш на чтение только на тех хостах, которые активно обслуживают этот блок и владеют им, а те хосты, которые просто хранят копию данных - в Read cache таких блоков не помещают.

Не так давно мы писали о том, что компания VMware выпустила виртуальный модуль VOVA (vSphere OpenStack Virtual Appliance), предназначенный для интеграции с архитектурой OpenStack, которая представляет собой комплекс проектов свободного программного обеспечения, предназначенного для построения облачной инфраструктуры.

На днях же VMware выпустила небольшой документ "Getting Started with OpenStack and VMware vSphere", в котором описывается схема того, как использовать решение vSphere в качестве бэкэнда для компонентов Nova (контроллер вычислительных ресурсов) и Cinder (облачные блочные хранилища).

В указанном руководстве все опирается на виртуальный модуль VOVA с Linux-машиной, которая реализует все необходимые сервисы OpenStack.

Структура документа:

• Introduction
  • VMware vSphere
  • OpenStack
  • Using OpenStack with vSphere
    • OpenStack and vSphere: Conceptual Analogies
  • The VMware OpenStack Virtual Appliance
• Requirements
  • vSphere Requirements
    • vSphere Inventory: Single Datacenter
    • Cluster: Automated VMware vSphere Storage DRS
    • Storage: Shared
    • Networking
      • Port Groups and VLANs
      • ESXi Firewall
      • DHCP Server
• Installation
  • Importing VOVA
  • Configuring VOVA
  • Starting VOVA
  • Configuring the VMware vSphere Web Client Plug-in for OpenStack
• Managing OpenStack with the Horizon Web Interface
  • Logging In – Web
  • Logging In – SSH/CLI
  • Flavor of the Day
  • Launching an Instance
  • Accessing the Console for an Instance
  • Managing Storage
    • Adding Persistent Storage to an Instance
    • Removing Persistent Storage from an Instance
    • Adding the Persistent Storage to Another Instance
  • Network

Надо отметить, что виртуальный модуль VOVA официально не поддерживается со стороны VMware и предоставляется "as is".

В небольших инсталляциях виртуальной инфраструктуры VMware vSphere может оказаться оправданным сделать один из серверов VMware ESXi сервером NTP, чтобы с ним синхронизировали свое время другие хосты.

Интересно, что немногие знают о том, что NTP-клиент сервера VMware ESXi 5.x (NTP-демон /sbin/ntpd) работает по-умолчанию не только как клиент, но и отдает время по запросу другим серверам как NTP-сервер. Поэтому достаточно лишь указать адрес хоста ESXi в качестве целевого хоста для синхронизации времени - и все будет работать.

Загвоздка тут одна - по умолчанию фаервол сервера ESXi блокирует входящие NTP-запросы по протоколу UDP на порт 123. Чтобы это исправить, нужно добавить собственное правило в сетевой экран. К сожалению, в Firewall GUI этой возможности не предусмотрено, поэтому придется лезть в конфиг-файл.

Для начала выведем список всех активных правил фаервола ESXi командой:

esxcli network firewall ruleset list

Создаем файл ntpd.xml с конфигурацией сервиса NTP со следующим содержимым (подробнее о процессе - тут):

<!-- Firewall configuration information for NTP Daemon -->
<ConfigRoot>
  <service>
      <id>NTP Daemon</id>
      <rule id='0000'>
          <direction>inbound</direction>
          <protocol>udp</protocol>
          <porttype>dst</porttype>
          <port>123</port>
      </rule>
      <enabled>false</enabled>
      <required>false</required>
  </service>
</ConfigRoot>

Далее кладем этот файл в папку на хосте ESXi /etc/vmware/firewall/ntpd.xml и выполняем команду:

esxcli network firewall refresh

После этого мы увидим новое правило в конфигурации сетевого экрана ESXi (в командной строке его можно проверить командой list, приведенной выше):

Однако, к сожалению, пользовательская конфигурация фаервола ESXi не сохраняется при перезагрузке хоста, о чем написано в KB 2007381. Поэтому можно просто положить ntpd.xml на общее хранилище и добавить в /etc/rc.local команду по копированию ntpd.xml в нужную папку хоста и комнду рефреша правил фаервола. Однако это ненадежно, поскольку зависит от доступности общего хранилища.

Поэтому, все-таки, лучше сделать это правило постоянным с помощью процедуры, описанной у Андреаса, заметка которого и стала основой этой статьи. Для этого нужно будет создать и установить VIB-пакет (как сделать это для любого случая описано в той же KB 2007381).

Ну а используя готовый пакет от Андреаса, можно установить созданный им VIB для добавления правила в фаервол для NTP-сервера:

esxcli software acceptance set --level CommunitySupported
esxcli software vib install -v http://files.v-front.de/fwenable-ntpd-1.2.0.x86_64.vib

Все это работает как для ESXi 5.0/5.1, так и для ESXi 5.5.

Настала пора посмотреть, какие темы в этом году в сфере виртуализации были у нас самыми актуальными и собрали больше всего просмотров. Поэтому мы просто сделали запрос к нашей базе и вывели статьи этого года, упорядоченные по количеству просмотров по убыванию.

Итак, как выглядит наш Топ-10 2013 года:

Неудивительно, что самым ожидаемым релизом этого года оказалась платформа виртуализации VMware vSphere 5.5. Каждый раз, когда выходит обновление vSphere, это делает маленькую революцию в сфере виртуализации. Ведь частные облака по-прежнему удерживают внимание ИТ-специалистов, и хост-платформа ESXi является лидирующим решением для построения корпоративных облачных инфраструктур.

Из технологий, которые оказались самыми интересными в vSphere 5.5 - это, конечно же, сервисы Virtual SAN, концепция Software Defined Networking (SDN) и продукт VMware NSX на ее основе, а также технология VMware Virtual Flash (vFlash).

Самый оживленный интерес вызвала именно версия View 5.2, у которой в названии добавилось еще слово Horizon, обозначающее принадлежность продукта к семейству решений из множества EUC (End User Computing).

Тут безусловные лидеры по интересу пользователей - функции 3D-графики в виртуальных ПК и технология Clientless HTML5 Access to View Desktops & Apps, позволяющая получать доступ к своим десктопам через браузер. Напомним, что не так давно вышла версия View 5.3, где функции по работе с 3D-графикой были значительно улучшены.

Как показывает статистика, тема переноса физических серверов в виртуальную среду по-прежнему актуальна. В статье рассказывается об основных аспектах процесса миграции P2V (Physical to Virtual) и средстве для автоматизации этого процесса - VMware Converter Standalone.

Оказывается, многим пользователям хочется подключить том VMFS к Windows-системе, чтобы скопировать его виртуальные машины, а далее заглянуть в содержимое их файлов виртуальных дисков (VMDK). Это возможно средствами драйвера Open Source VMFS Driver от fluid Ops. Жалко, что это средство поддерживается только для VMFS 3 и уже давно не обновляется.

Похвально, что тяга к знаниям находится у наших ИТ-специалистов так высоко. Скорее всего, заметка набрала много просмотров из-за того, что ссылку на нее часто пересылали.

Помимо решения для виртуализации настольных ПК VMware View, комплект Horizon Suite включает в себя VMware Horizon Mirage 4.0 - решение для управления образами рабочих станций пользователей, а также VMware Horizon Workspace 1.0 - комбинацию двух продуктов - Horizon Data (бывший Project Octopus - решение а-ля корпоративный Dropbox, о котором мы много писали вот тут) и Horizon Application Manager - решение для федерации SaaS-приложений и VDI-сервисов.

Тема резервного копирования хостов конфигурации хостов ESXi всегда востребована. Текущая версия этой утилиты (1.2) вышла в конце февраля этого года. Жаль, что не обновляется.

Конечно же, выпуск решения номер 1 для резервного копирования и репликации Veeam Backup and Replication 7 стал одним из главных событий этого года.

О каждой из новых функций решения можно почитать по этим ссылкам:

• Поддержка решения VMware vCloud Director (возможность №1)
• Плагин для vSphere Web Client (№2)
• Восстановление объектов Microsoft SharePoint (№3)
• Поддержка ленточных библиотек (№4)
• Поддержка виртуальных лабораторий по запросу (On-Demand Sandbox) для Hyper-V (№5)
• Улучшенный 1-Click Restore (№6)
• Виртуальные лаборатории для реплик (№7)
• Копирование резервных копий в географически удаленное хранилище по WAN-соединению (№8)
• Резервное копирование виртуальных машин из снапшотов, сделанных на уровне хранилищ (№9)

Действительно, полезный и нужный продукт.

Кто-то предрекал XenServer скорую смерть (в том числе, и мы), но он оказался живее всех живых. Citrix решила передать платформу XenServer сообществу Open Source, что может вдохнуть вторую жизнь в этот многострадальный продукт.

Действительно интересный пост наших коллег из компании ИТ-ГРАД, в котором рассказывается о Cisco UCS Manager, с помощью которого производится настройка всей системы. Данную задачу специалисты ИТ-ГРАД выполнили в рамках подготовки к тестированию FlexPod (Cisco UCS + NetApp в режиме MetroCluster) для одного из заказчиков.

На этом наш хит-парад закончен. Странно, что в него не попали статьи про новый Hyper-V (например, "Что нового будет в Hyper-V обновленного Windows Server 2012 R2", 12 место по популярности), но это объясняется, скорее всего, тем, что нас читают, в основном, любители VMware. Что ж, будем исправляться и поднажмем на заметки о решениях компании Microsoft, тем более, что она потихоньку откусывает свою долю рынка у VMware.

Всего в этом году у нас появилось 447 заметок о виртуализации и решениях для управления виртуальной инфраструктурой. Будем ждать вас уже в следующем году! С Наступающим Новым годом!

Мы уже много писали о технологии VMware Virtual SAN (VSAN), которая позволяет создать отказоустойчивый кластер хранилищ для виртуальных машин на основе комбинации SSD+HDD локальных дисков серверов VMware ESXi. Не так давно вышла обновленная бетаэтого решения, кроме того мы не так давно писали о производительности VSAN тут.

В этой заметке (на базе статьи Дункана) мы поговорим о том, как кластер VSAN обрабатывает сбои различного типа, и как происходит восстановление работоспособности виртуальной машины без ее простоя.

Итак, в нормальном режиме функционирования, при значении параметра FailuresToTolerate равном 1, который означает, какое количество отказов хостов может пережить кластер хранилищ, реплика одного VMDK будет размещена на дисках еще одного из хостов кластера:

Тут можно заметить 5 особенностей кластера VMware VSAN:

• Виртуальный диск VMDK и его реплика всегда находятся на разных хост-серверах VMware vSphere.
• ВМ не обязательно должна исполняться на том хосте ESXi, на дисках которого находятся ее хранилища.
• Компонент witness находится на третьем по отоношению к виртуальному диску и его реплике хосте, чтобы создать определенность на случай разделения сети VSAN (где окажется 2 компонента из набора "vmdk-реплика-witness" - тот сегмент и будет определяющим).
• Сеть VSAN используется для операций ввода-вывода и определения доступности.
• Реплика VMDK-диска вместе с основной копией образуют RAID-1 массив, который увеличивает производительность операций чтения в виртуальной машине, так как для чтения используются оба хранилища.

Кроме того, вследствие особенностей реализации кластера VSAN, надо понимать, что команды ввода-вывода не применяются к диску данных виртуальной машины, пока не пришло подтверждение об их записи на реплике. Но подтверждение приходит не от HDD-диска, где находятся данные ВМ (это было бы очень медленно), а от SSD-диска, который используется как энергонезависимый Write Buffer для команд ввода вывода. Таким образом, этот буфер (и данные, само собой) зеркалирован в рамках дисковой группы на другом хосте ESXi.

Теперь рассмотрим различные виды сбоев в кластере VSAN.

1. Ломается диск дисковой группы, где исполняется виртуальная машина.

Выглядит это так:

В этом случае такой диск сразу же помечается как "degraded", а команды ввода-вывода перенаправляются на другой хост-сервер VMware ESXi. При этом виртуальная машина этого не замечает, так как переключается на работу с SSD-буфером/кэшем и HDD-дисками другого хоста мгновенно (данные на момент сбоя были синхронизированы, ничего не потерялось).

Одновременно с этим сразу же начинается процесс построения реплики на другом хосте ESXi в рамках его дисковой группы, при этом проверяется, достаточно ли там свободных дисковых ресурсов. Если их недостаточно, то механизм VSAN будет ожидать. Как только вы добавите диски/дисковые группы на хостах - сразу же начнется процесс построения реплики (до его окончания машина будет помечена как "degraded").

Тут надо отметить, что в degraded-состоянии скорость записи данных останется прежней, простоя не будет, а вот скорость чтения упадет до построения новой реплики, поскольку второй копии данных пока нет.

2. Отказывает хост VMware ESXi целиком.

В этом случае запускать процесс восстановления сразу же, конечно, не нужно - мало ли что могло случиться с хостом, например, его случайно перезагрузили, или временно пропало сетевое соединение.

В этом случае происходит ожидание в течение 60 минут, и если отказавший хост ESXi не оживет, то начнется процесс создания реплики виртуального диска VMDK на другом хосте. Это время можно изменить в расширенной настройке кластера VSAN.ClomRepairDelay, но пока не известно будет ли это поддерживаться со стороны VMware.

3. Отказ SSD-диска в дисковой группе.

В кластере VMware Virtual SAN поддерживается 1 SSD-диск и до 7 HDD-дисков в одной дисковой группе. Всего на один хост VMware ESXi поддерживается до 5 дисковых групп.

В данном случае Failure Domain - это вся дисковая группа, включающая в себя SSD-диск, который используется для двух типов операций:

• Read Cache (70% емкости) - безопасное кэширование операций на чтение. На SSD-диске хранятся наиболее часто используемые блоки, что уменьшает I/O read latency для ВМ.
• Write Buffering (30% емкости) - когда приложение внутри гостевой ОС пытается записать данные, оно получает подтверждение записи тогда, когда данные фактически записаны на SSD (не на HDD), таким образом твердотельный накопитель используется как буфер на запись, что небезопасно при внезапном пропадании питания или отказе хоста. Поэтому данные этого буфера дублируются на других хостах кластера и их SSD-дисках.

Таким образом, при отказе SSD-диска, виртуальная машина начинает использовать реплику на уровне всей дисковой группы на другом хосте VMware ESXi. Вот почему выгодно делать две дисковых группы 3HDD+1SSD, чем одну  6HDD+1SSD.

Вот, в общем-то, и все. Более подробно об использовании SSD-дисков, их производительности и ресурсе можно прочитать вот в этой статье.

Не так давно мы уже писали про новые возможности vGate R2 версии 2.6 - продукта, предназначенного для защиты виртуальных инфраструктур средствами политик, а также от несанкционированного доступа к элементам инфраструктуры, таким как виртуальные машины, хранилища и сети.

В этом посте мы расскажем о том, как начать работу со средством vGate R2 2.6 для быстрого старта. Для более подробной информации обращайтесь к разделу документации о vGate 2.6 - благо, что она доступна на русском языке.

Напомним также, что демо-версия vGate 2.6 с поддержкой последней версии платформы VMware vSphere 5.5 доступна для скачивания по ссылке.

1. Итак, устанавливаем vGate 2.6 из дистрибутива:

2. Во время первого запуска консоли управления vGate на экране появится мастер
первоначальной настройки:

Укажите с помощью мастера параметры соединения с сервером виртуальной инфраструктуры, добавьте защищаемые серверы и создайте учетные записи для пользователей vGate.

3. По окончании работы мастера на экране появится окно консоли управления.

Если первоначальная настройка конфигурации не была выполнена с помощью мастера, выполните ее самостоятельно (пункты 4–6).

Читать статью далее ->>

Мы уже много писали о публичном облаке VMware vCloud Hybrid Service (vCHS), которое еще пока недоступно в России, но уже серьезно набирает обороты в штатах (и скоро будет в UK). Также некоторые из вас помнят, что VMware предлагает средство vCloud Connector, которое представляет собой бесплатный плагин к VMware vCenter (управляется через Web Client), с помощью которого пользователь частной виртуальной инфраструктуры может перемещать свои виртуальные машины в облако сервис-провайдера, который также работает на платформе VMware.

Однако до настоящего момента так и не было полноценного средства, позволяющего объединить частную инфраструктуру предприятия и соответствующий сегмент публичного облака vCHS (в том числе, на базе технологий VXLAN). Теперь такая возможность есть - вышел VMware vCloud Hybrid Service vSphere Client Plug-in 1.0.

Данный плагин работает только под vSphere Web Client версии 5.5. С помощью плагина можно делать следующие вещи:

• Администрировать ресурсы на стороне публичного облака VMware (как в режиме Dedicated Cloud, так и в режиме Virtual Private Cloud).
• Просматривать инвентори виртуальных машин и управлять виртуальными датацентрами.
• Развертывать виртуальные машины из шаблонов, находящихся в каталоге, а также изменять конфигурацию существующих ВМ.
• Автоматически получать обновления любых изменений, сделанных через vCHS web portal.

Системные требования для установки плагина:

• vSphere Web Client 5.5  (старый C+ Client не поддерживается).
• Аккаунт на vCloud Hybrid Service.
• Совместимые браузеры:
  • Windows: Firefox, Chrome и Internet Explorer.
  • Mac: Chrome и Safari (доступ к консоли ВМ не работает для Mac).
  • Linux: Firefox и Chrome.

Однако плагин не заменяет основной портал VMware vCHS, так как только там можно делать следующее:

• Создавать или изменять роли пользователей.
• Добавлять пользователей к виртуальным датацентрам.
• Создавать новые виртуальные сети.
• Настраивать шлюзы и сетевые службы, такие как сетевой экран и NAT.
• Настраивать бэкап виртуальных машин.
• Просматривать виртуальные ресурсы по регионам.

На сайте VMware есть интересные презентации на тему vCHS vSphere Client Plug-in:

• Установка плагина vCloud Hybrid Service vSphere Client Plug-in
• Соединение с облаком vCHS через vCHS vSphere Client Plug-in
  
• Возможности плагина vCHS vSphere Client Plug-in

Документация доступна по этой ссылке (самый полезный док тут), а скачать vCloud Hybrid Service vSphere Client Plug-in можно по этой ссылке.

Мы очень много писали о том, как с помощью утилиты esxtop можно собирать с хостов VMware ESXi данные о производительности и различные метрики (например, тут и тут). Данные, полученные с помощью этой утилиты, очень часто помогают разобраться в источнике проблем в части вычислительных ресурсов, хранилищ и сетевого взаимодействия.

В этой заметке мы поговорим немного о визуализации данных esxtop. Не так давно мы писали об утилите VisualEsxtop, которая как раз тем самым и занимается - строит графики по наборам данных. Но недавно мы наткнулись на простой способ, позволяющий с помощью Windows Perfmon сравнивать наборы данных esxtop с разных хостов ESXi.

1. Итак, сначала нужно собрать данные с хоста ESXi в пакетном режиме в файл .csv. Например:

Здесь:

• -b - означает пакетный режим работы утилиты.
• -d (delay) - промежуток между срезами сбора данных.
• -n - число число таких срезов (сэмплов).

В данном случае будет собрано 360 сэмплов данных с промежутком в 10 секунд, то есть сбор займет 1 час.

Можно сжать результаты, чтобы экономить место на хосте, командой:

esxtop -b -d 10 -n 360 | gzip > esxtopresults.csv.gz

2. Загружаем данные в Windows Perfmon, выбрав источник - наш файл csv:

Визуализируем нужные счетчики:

3. Пробуем добавить еще один csv с другого хоста ESXi (с которым мы хотим сравнить данные первого хоста), но нам говорят, что так нельзя - можно такие файлы смотреть только по одному:

Не беда - сохраняем данные как бинарный файл с расширением *.blg, выбрав нужные счетчики:

Дальше просто удаляем этот файл из источников данных Perfmon, добавляем второй csv-файл и так же сохраняем его как *.blg.

Ну а дальше оба этих файла добавляем по одному - и все работает:

Добавляем сохраненные счетчики:

И данные с обоих хостов показываются на одном графике:

Источник заметки: www.viktorious.nl.

Не так давно мы уже писали про новые возможности технического релиза vGate R2 версии 2.6 - продукта, предназначенного для защиты виртуальных инфраструктур VMware. Там мы описали основные новые фичи решения, которое уже, кстати, доступно для загрузки в демо-версии, а в этой статье рассмотрим их подробнее, приведем несколько скриншотов и комментариев.

Многие администраторы и разработчики для своих целей используют VMware ESXi, работающий в виртуальной машине (так называемый Nested ESXi). Туда даже можно ставить свои VMware Tools.

При этом, когда требуется использовать виртуальные ESXi, как правило, их требуется несколько штук. Есть три способа получить их:

• Поставить заново и настроить - самый надежный, но долгий.
• Использовать процедуру автоматической установки и настройки Kickstart. Но тут надо знать, как это делается.
• Склонировать существующий экземпляр ESXi - самое простое решение, но сделать это нужно правильно.

Вильям Лам описал третий вариант процедуры подготовки ESXi к клонированию, после проведения которой можно развертывать эти инстансы легко и просто. В результате у новых ESXi будут свои MoRef ID, UUID, BIOS UUID и MAC-адреса.

Итак, что нужно сделать:

1. Смена MAC-адреса VMkernel при смене MAC-адреса сетевого интерфейса VM Network.

Если развертывать новый ESXi с новым MAC-адресом Virtual machine network, то необходимо также поменять MAC-адрес VMkernel. Для этого есть настройка FollowHardwareMac, которая позволяет делать это автоматически.

Для этого выполняем команду консоли ESXCLI:

esxcli system settings advanced set -o /Net/FollowHardwareMac -i 1

2. Удаляем упоминание об UUID из esx.conf.

Запись о системном UUID сервера ESXi хранится в основном конфигурационном файле esx.conf (/etc/vmware/esx.conf). Нужно удалить строчку с упоминанием этого UUID - и тогда он сгенерируется при следующей загрузке.

После этого можно выключать ВМ с виртуальным VMware ESXi и клонировать ее. При загрузке новой ВМ, естественно, нужно поменять IP-адрес и прочую сетевую идентификацию.

В комментариях к заметке Вильяма пишут, что такой способ можно использовать для клонирования LUN, содержащего образ для загрузки ESXi по SAN.

При каждом релизе платформы виртуализации VMware vSphere неизменно возникают вопросы о том, что же изменилось в плане поддержки гипервизором ESXi кластеров Microsoft Clustering Services (MSCS). Напомним, что базовая информация об этом находится здесь.

Вот какие варианты развертывания кластеров MSCS для различных приложений поддерживает VMware vSphere 5.5 (напомним, что о кластерах MSCS мы писали тут, тут и тут):

А вот какие версии и конфигурации кластеров Microsoft поддерживаются для различных верси гостевых ОС Windows Server и VMware vSphere:

А теперь перейдем к нововведениям, касающимся поддержки MSCS в VMware vSphere 5.5:

1. Во-первых, к общему хранилищу узлов кластера MSCS может быть организован доступ по нескольким путям посредством политики Round Robin (модуль PSP_RR). Ранее это сделать было нельзя ввиду проблем со SCSI reservations. Теперь эта проблема решена.

Однако тут есть ограничения:

• Поддерживается только для гостевых ОС Windows 2008 и Windows 2012.
• Поддерживаются только конфигурации Cluster Across Boxes (CAB) и N+1. Системы "Cluster in a box" (CIB) используют Virtual Reservations.
• Общий диск (Quorum или Data) должен быть развернут в режиме pass-through RDM.

2. Во-вторых, появилась поддержка протоколов FCoE & iSCSI. Ранее полноценно в качестве общего хранилища для кластеров MSCS поддерживались только  хранилища Fibre Channel, с оговорками iSCSI и как-то частично FCoE. Теперь же полноценно можно использовать iSCSI и FCoE хранилища.

А именно:

• Все конфигурации кластеров: CAB, CIB и N+1 поддерживаются iSCSI.
• Поддержка адаптеров iSCSI:
  
  • Software iSCSI;
  • Аппаратные адаптеры QLogic, Emulex и Broadcom.
• Поддержка режима Mixed mode для iSCSI-инициатора.
• До 5 узлов в кластере поддерживается для Windows 2008 SP2 и более поздних версий.

3. В-третьих, появилась поддержка кластеризации гостевых ОС Windows 2012 MSCS.

Если все это обобщить, то получится картинка, взятая отсюда:

Больше подробностей о поддержке MSCS в VMware vSphere 5.5 можно узнать из KB 2052238.

Как многие знают, в VMware vSphere 5.5 появились возможности Virtual SAN, которые позволяют создать кластер хранилищ для виртуальных машин на основе комбинации SSD+HDD локальных дисков серверов VMware ESXi. Не так давно вышла обновленная бета этого решения, кроме того мы не так давно писали о производительности VSAN тут и тут.

Сегодня же мы поговорим о том, как нужно сайзить хранилища Virtual SAN в VMware vSphere, а также немного затронем тему отказоустойчивости. Более детальную информацию можно найти в VMware Virtual SAN Design & Sizing Guide, а ниже мы расскажем о подходе к планированию хранилищ VSAN вкратце.

Объекты и компоненты Virtual SAN

Начнем с простого ограничения по объектам (objects) и компонентам (components), которое есть в VSAN. Виртуальные машины, развернутые на vsanDatastore, могут иметь 4 типа объектов:

• Домашняя директория виртуальной машины Virtual Machine ("namespace directory").
• Объект файла подкачки - swap object (для включенной ВМ).
• Виртуальный диск VMDK.
• Дельта-диски для снапшотов. Каждый дельта-диск - это отдельный объект.

Каждый объект, в зависимости от типа RAID, рождает некоторое количество компонентов. Например, один VMDK, размещенный на двух томах страйпа (RAID 0) рождает два объекта. Более подробно об этом написано вот тут.

Так вот, ограничения тут следующие:

• Максимальное число компонентов на 1 хост ESXi: 3000.
• Максимальное число компонентов для одного объекта: 64 (это включает в себя тома страйпов и также реплики VMDK с других хостов).

На практике эти ограничения вряд ли актуальны, однако о них следует знать.

Сколько дисков потребуется для Virtual SAN

Во второй бета-версии VSAN (и, скорее всего, так будет в релизной версии) поддерживается 1 SSD-диск и до 7 HDD-дисков в одной дисковой группе. Всего на один хост VMware ESXi поддерживается до 5 дисковых групп. Таким образом, на хосте поддерживается до 5 SSD-дисков и до 35 HDD-дисков. Надо убедиться, что контроллеры хоста поддерживают необходимое количество дисков, а кроме того нужно проверить список совместимости VSAN HCL, который постоянно пополняется.

Также надо учитывать, что кластер хранилищ Virtual SAN поддерживает расширение как путем добавления новых дисков, так и посредством добавления новых хостов в кластер. На данный момент VMware поддерживает кластер хранилищ максимум из 8 узлов, что суммарно дает емкость в дисках в количестве 40 SSD (1*5*8) и 280 HDD (7*5*8).

Сколько дисковой емкости нужно для Virtual SAN (HDD-диски)

Необходимая емкость под размещение VMDK зависит от используемого параметра FailuresToTolerate (по умолчанию 1), который означает, какое количество отказов хостов может пережить кластер хранилищ. Если установлено значение 1, то реплика одного VMDK будет размещена на дисках еще одного из хостов кластера:

Тут можно сказать о том, как работает отказоустойчивость кластера Virtual SAN. Если отказывает хост, на котором нет виртуальной машины, а есть только VMDK или реплика, то виртуальная машина продолжает работу с основной или резервной копией хранилища. В этом случае начнется процесс реконструкции реплики, но не сразу - а через 60 минут, чтобы дать время на перезагрузки хоста (то есть если произошел не отказ, а плановая или внеплановая перезагрузка), а также на короткие окна обслуживания.

А вот если ломается хост, где исполняется ВМ - начинается процедура восстановления машины средствами VMware HA, который перезапускает ее на другом хосте, взаимодействуя при этом с Virtual SAN.

Более подробно этот процесс рассмотрен вот в этой статье и вот в этом видео:

Однако вернемся к требующейся нам емкости хранилищ. Итак, если мы поняли, что значит политика FailuresToTolerate (FTT), то требуемый объем хранилища для кластера Virtual SAN равняется:

Capacity = VMDK Size * (FTT + 1)

Что, в принципе, и так было очевидно.

Сколько дисковой емкости нужно для Virtual SAN (SSD-диски)

Теперь перейдем к SSD-дискам в кластере VSAN, которые, как известно, используются для вспомогательных целей и не хранят в себе данных виртуальных машин. А именно, вот для чего они нужны (более подробно об этом тут):

• Read Cache - безопасное кэширование операций на чтение. На SSD-диске хранятся наиболее часто используемые блоки, что уменьшает I/O read latency для ВМ.
• Write Buffering - когда приложение внутри гостевой ОС пытается записать данные, оно получает подтверждение записи тогда, когда данные фактически записаны на SSD (не на HDD), таким образом твердотельный накопитель используется как буфер на запись, что небезопасно при внезапном пропадании питания или отказе хоста. Поэтому данные этого буфера дублируются на других хостах кластера и их SSD-дисках.

Так каковы же рекомендации VMware? Очень просты - под SSD кэш и буфер неплохо бы выделять 10% от емкости HDD-дисков хоста. Ну и не забываем про значение FailuresToTolerate (FTT), которое в соответствующее число раз увеличивает требования к емкости SSD.

Таким образом, необходимая емкость SSD-хранилищ равна:

Capacity = (VMDK Size * 0.1) * (FTT + 1)

Ну и напоследок рекомендуем отличнейший список статей на тему VMware Virtual SAN:

• VSAN Part 1 – A first look at VSAN
• VSAN Part 2 – What do you need to get started?
• VSAN Part 3 – It is not a Virtual Storage Appliance
• VSAN Part 4 – Understanding Objects and Components
• VSAN Part 5 – The role of VASA
• VSAN Part 6 – Manual or Automatic Mode
• VSAN Part 7 – Capabilities and VM Storage Policies
• VSAN Part 8 – The role of the SSD
• VSAN Part 9 – Host Failure Scenarios and vSphere HA interop
• VSAN Part 10 – Changing VM Storage Policy on-the-fly

Как вы знаете, у каждого софтверного вендора есть свои политики по обеспечению жизненного цикла своих продуктов и их поддержке. VMware тут не исключение - компания предоставляет эти политики всем желающим в открытом доступе. Наиболее интересными тут являются политики, касающиеся жизненного цикла - какие стадии продукт проходит от рождения - "General Availability" (GA) - до официальной смерти "End of Availability".